ci: 合并时收口另一个仓库里被 Fixes 声明的 issue（缺凭据时改为出声，不静默） - #4553
Merged
Conversation
GitHub's closing keywords only act within a repository, so a PR here saying `Fixes objectstack-ai/objectui#456` merges and leaves that issue open — with no reference to the PR on the issue either. v17 verification hit this twice (#4475, #4478); both were closed by hand. The job has two modes and both are visible: with a cross-repo token it closes the foreign issue and links the PR; without one it comments on the merged PR naming what still needs closing. Silent no-op on a missing secret is the shape this repo keeps having to fix (#4449), so the absent credential announces itself instead.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
github-actions
Bot
added
documentation
os-zhuang
marked this pull request as ready for review
August 2, 2026 07:41
Contributor
Author
更正：正文「验证」一节里有一句声明站不住原文写的是：
这句很可能不成立，不应作为验收依据。
更正后的验证状态如实列一遍：
也就是说：这个工作流的运行时行为一次都没有被真正执行过。 静态检查只能保证它不会因语法错误而崩，保证不了它在真实事件下做对事。 合并后建议主动确认一次：下一个带跨仓库 （本条更正由协调会话在合并前补记——正文里那句话是我写的，属于「声称验证过、实际没有」的那一类，而这恰恰是本批次 #4482 反复在修的问题。留一条更正比让它随合并固化便宜得多。） Generated by Claude Code |
akarma-synetal
pushed a commit
to akarma-synetal/framework
that referenced
this pull request
Aug 3, 2026
…引入的红检查） (objectstack-ai#4573) * fix(ci): rename the cross-repo client — github-script already declares `octokit` `actions/github-script` injects an `octokit` binding, so `const octokit = ...` aborts the run with a SyntaxError before any logic executes. Caught on objectstack-ai#4553's own merge, the first time the workflow ever ran; until this lands every merged PR carries one red check. The pre-merge `node --check` missed it because the test wrapper declared only {github, context, core, require} — a wrapper that omits an injected identifier cannot see a collision with it. The wrapper now carries the full set. * ci: log CROSS_REPO_ISSUE_TOKEN presence on every run Without this the job returns early whenever a PR body carries no cross-repo reference — which is most PRs — so a repository that has the secret and one that does not produce byte-identical logs. Whether the credential is provisioned stays unanswerable until a cross-repo reference happens to show up, possibly days later. Presence only; the value is never read into the log. --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GitHub 的关闭关键字只在同仓库内生效。本仓库一个写着
Fixes objectstack-ai/objectui#456的 PR，在人眼里和同仓库关闭长得完全一样，合并后那个 issue 却会永远开着——而且目标 issue 页面上也不会出现这条 PR 的任何引用，下一个读者无从找到修复在哪。v17 验收批次（#4482）撞了两次：#4475 与 #4478 的修复都落在 objectui，两个 framework 侧 issue 都是人工关掉的。这次是把那两次手工动作固化下来。
两种模式，都可见
第二种模式是刻意设计的，不是降级凑合。
本仓库现有的 secret 只有
GITHUB_TOKEN与NPM_TOKEN，而GITHUB_TOKEN的写权限被限制在运行工作流的那个仓库内——它关不掉另一个仓库的 issue，这正是本问题的成因。所以在管理员配置跨仓库凭据之前，这个工作流没有能力完成关闭动作。那种情况下它必须出声。一个因为 secret 从未配置而悄悄什么都不做的工作流，正是这个仓库反复在修的形状——#4449 的
validateFormLayout写了、测了、导出了，却没有任何命令调用它，"它存在多久，就在零个 stack 上跑了多久"。缺失的凭据必须自己announce，而不是让人以为已经接好了。需要管理员做的事（本 PR 无法自带）
新增仓库 secret
CROSS_REPO_ISSUE_TOKEN：对目标仓库具备issues: write的 fine-grained PAT 或 GitHub App token。组织里已安装的 GitHub App 即可胜任，不必用个人 PAT。配置前后行为都正确，只是能力不同；配置后本 PR 的提示评论会自动不再出现。
实现要点
owner/repo#N。裸#N由 GitHub 原生处理，绝不触碰。已自测：Fixes #4441不命中，Fixes objectstack-ai/objectui#3134命中。thisRepo比较），否则每次合并都会在已被 GitHub 关闭的 issue 上多留一条无意义评论。core.warning而非静默——一次失败不能读起来像成功。pull_request_target而非pull_request，因为后者对来自 fork 的运行不下发 secret。pull_request_target通常的风险（用写权限运行不受信任的 PR 代码）在这里不成立：本 job 从不 checkout head ref，也从不执行 PR 里的任何东西，只读 PR 正文并调用 issues API。验证
actions/github-script的 async 包装做node --check，语法通过。Fixes #4441不命中。pull_request_target: closed且merged == true时运行，本 PR 自身合并即是它的第一次真实执行——届时它应当因缺少 token 而在本 PR 上留下那条提示评论，这本身就是可观察的验收信号。配套的同名工作流已在 objectui 侧一并提交（方向相反：那边的 PR 修本仓库的 issue）。
Generated by Claude Code